Add plugin entry: antigravity-acp - #131

Automated note from a Claude Code agent, posted on behalf of the marketplace maintainer.

Thanks for the submission — we really want to get this in. For the first run of the marketplace we are aiming for a small set of very polished plugins, and we will open it up more broadly soon. Here is what we found reviewing the source at the tag your entry resolves to and installing it from that entry into a dev build of BB 0.40:

Blocker 1: the plugin fails to install

Installing git:https://github.com/rawizhere/bb-plugin-antigravity-acp.git@^0.1.0 (resolves to v0.1.2) into a dev build of BB 0.40 fails:

install failed: host bundle build for "antigravity-acp" failed:
host.ts:14:7: ERROR: Could not resolve "@get-bb/plugin-sdk/provider-bridge/acp"

We reproduced it standalone. The cause is a stale package-lock.json: your package.json correctly has @get-bb/plugin-sdk: 0.4.22 in dependencies, but the lockfile still marks node_modules/@get-bb/plugin-sdk with "dev": true from when it was a devDependency. BB's managed git install runs npm install --ignore-scripts --omit=dev --omit=optional, which honours the lockfile, so the SDK never lands on disk — and unlike the SDK root, provider-bridge/acp is deliberately not stubbed by the builder (it is real published code, not a host-implemented shim), so the bundle cannot resolve it.

Fix: delete package-lock.json, re-run npm install, commit, and re-tag. You can verify with npm install --ignore-scripts --omit=dev --omit=optional && bb plugin build . in a clean checkout.

Blocker 2: the plugin id collides with an earlier submission

PR #102 claims the same entries/antigravity-acp.json. We looked carefully at whether either is a copy of the other, and they are not — diff -r shows zero identical files and the architectures are genuinely different (you re-export the canonical SDK bridge and run Google's long-lived agy_acp_server.par; theirs is a hand-written 546-line bridge shelling out to the agy CLI per turn). This is two people picking the same id from the same bb-plugin-<id> convention.

We are awarding the id to #102 on priority: its repo and marketplace PR both predate yours by 5 days, it is MIT-licensed, and a third-party plugin (bb-plugin-usage) already has a merged integration reading the on-disk format it writes.

We would like to list yours too — please rename to a non-colliding id. antigravity-acp-server, antigravity-acp-official or google-antigravity-acp all describe it accurately, and yours is the one that wraps Google's official ACP server. The entry filename, the icons/ asset name and package.json's name all need to change together. Note there is no runtime conflict between the two — you register provider acp-antigravity, they register antigravity.

Also worth fixing

• The downloaded binary is neither checksummed nor signature-verified. install.ts:165-176 streams an arbitrary URL to disk, :330 chmod 0o755s it, :209-225 symlinks it onto PATH, and the ACP bridge then executes it every turn. The URL is not pinned: fetchDistMap() (:117-143) fetches agentclientprotocol/registry on main, unauthenticated, no pinned commit. Anyone who can land a commit there gets arbitrary-binary-on-PATH on every machine that runs bb antigravity-acp install afterwards. In its favour: it is an explicit opt-in command, and we checked the live registry — its five dl.google.com URLs are character-for-character identical to your FALLBACK_DIST (:26-54), so the fallback is an honest mirror. Please add a SHA-256 check against a pinned digest, or at minimum pin the registry to a commit SHA.
• Zip-slip on extraction. extractZip (:178-201) shells to tar -xf for zips on macOS/Windows, and bsdtar does not sanitize ../ the way unzip and Python's zipfile.extractall do. Compounding it, helperNameIn (:203-207) links any extracted file matching /^localharness.*/ onto PATH (:347-352). Fixing the trust root above closes this too.
• Linux launch args are dropped. server.ts:42 hardcodes args: [], but the ACP registry specifies args: ["--uid="] for linux-x86_64 and linux-aarch64 (we confirmed against the live registry). You read entry.args into DistEntry and never use it, so the server may fail to launch on Linux.
• AGY_ACP_INSTALL_FROM (install.ts:296) silently redirects the download from an env var with no confirmation. Prefer the explicit --from flag.
• Windows PATH mutation. appendUserPathWindows (:227-239) runs setx Path to permanently modify HKCU\Environment, announced only in a post-hoc note. It also inherits setx's 1024-char truncation hazard.
• No LICENSE file, and package.json has no license field.
• Leftover template cruft: package.json:22-36 lists sonner, vaul, @pierre/diffs etc., and tsconfig.json includes app.tsx, components, lib, hooks — none of which exist.

What we liked

This is the cleanest of the three ACP submissions we looked at. It delegates all protocol work to the SDK bridge instead of hand-rolling it, uses execFile with array args throughout so there is no injection surface, touches no secrets, and — unlike a sibling submission — does not auto-install anything. It also matches BB's own first-party house style closely: acp-<agent> provider id, experimental_visibility: "installed", branding.icon as a plugin-relative SVG. Typecheck is clean against the published SDK.

Thanks for the detailed review — both PRs are updated. New release published: v0.2.0 at https://github.com/rawizhere/bb-plugin-antigravity-acp (marketplace entry range is now ^0.2.0).

Blocker 1 — install failure: fixed

package-lock.json was rebuilt from scratch, so @get-bb/plugin-sdk is no longer marked dev: true in the lockfile. Verified in a clean checkout exactly as you suggested:

npm install --ignore-scripts --omit=dev --omit=optional   # SDK lands on disk
bb plugin build .                                          # passes

npm ci and tsc --noEmit also pass.

Blocker 2 — id collision: renamed to google-antigravity-acp

• Package name: bb-plugin-google-antigravity-acp
• Entry filename: entries/google-antigravity-acp.json
• Icon asset: icons/google-antigravity-acp-ef068db2.svg
• CLI: bb google-antigravity-acp install / status
• Provider id stays acp-antigravity, so there is still no runtime conflict with #102's antigravity.

Security items from the review

• Registry pinning: the ACP registry is now fetched from a pinned commit (REGISTRY_COMMIT in install.ts), never from an unpinned main branch — a registry compromise can no longer push an arbitrary binary onto PATH.
• AGY_ACP_INSTALL_FROM removed: the download source is explicit only (--from <url-or-zip>); no env-var redirect.
• Zip-slip: tar is no longer used at all. Extraction is unzip → validated python3 zipfile (refuses ../ and absolute entries) on macOS/Linux, and PowerShell Expand-Archive on Windows (bsdtar's unsanitized ../ handling is gone).
• Windows PATH: mutation is now an explicit opt-in via --update-path, with a guard for setx's 1024-char truncation; the default only prints instructions.
• Linux launch args: the registry's args: ["--uid="] for linux are now used in the launch spec (per server platform) and recorded in the install manifest; status prints the effective launch args.
• LICENSE: added MIT license file and license field; removed template cruft from package.json/tsconfig.json.

Validation

• Marketplace npm run build passes (83 entries).
• npm run check liveness: my entry passes; the only failures are pre-existing on main (taskboard, usage-tracker — their npm packages 404), unrelated to this submission.

Ping for re-check — thanks!